Hey, thanks for your contribution. Rectangular pad support would be a great feature.

Couple comments:

• I'm not a fan of having one more separate property, i.e. base_shape. It adds unnecessary complexity. We should be able to provide this feature as part of the motion_constraint property, which it logically belongs to. Renaming the default NONE to OVAL may be appropriate in this case.
• Hijacking the onDrag(degrees, offset) callback to return two parameters that are not degrees and offset is not acceptable from a library point of view. The interface must not be misleading the library user. One solution may be to change our existing interface to return normalized offset values as in your solution, and then provide some static utility methods (or simply example code) to convert to degrees and offset for users who want the current output.

The situation is quite interesting in that the motion_constraint is closely related to the sort of information a user would want in the onDrag callback. For example, for the HORIZONTAL and VERTICAL constraints you typically really only want a single normalized value [-1, 1]. For your rectangular pad case you want two normalized values. For the oval case an angle value is likely more useful.

As I noted in the README, I'd like to see some way to easily create and plug in arbitrary motion constraints, be it an oval, rectangle, diamond, or squiggly path. Perhaps this is a good opportunity to explore some sort of API for accomplishing this?

What do you think?

yes, customize motion_constraint is a better solution. 👍